• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    Device (130) included in a communication system comprising a LoRa terminal (160A), said terminal, and a LoRa server (150), said server, each LoRa frame exchanged between the terminal and the server having to pass through a counter and a concentrator data included in a first communication network by on-line carrier currents of an automatic meter reading management system (120A, 120B, 120C, 120D, 120E), said counters being attached to at least one data concentrator (110 ) via the first network, at least one of said counters implementing a LoRa gateway and comprising a communication interface (114) enabling it to exchange LoRa frames with said terminal. The device is connected to each data concentrator via a second network (103) and to the server via a third network (102) and in that each LoRa frame exchanged between said terminal and the server transits through the device, each LoRa frame exchanged between the device and the server is encapsulated in a frame conforming to a frame format that the server would exchange with a LoRa gateway.
    公开号:FR3084233A1
    申请号:FR1856654
    申请日:2018-07-18
    公开日:2020-01-24
    发明作者:Henri TEBOULLE；Marc Le Gourrierec；Franck Harnay
    申请人:Sagemcom Energy and Telecom SAS；
    IPC主号:
    专利说明:

    The present invention relates to a device and a method for transporting frames sent by a terminal over a long-range wireless network with low power consumption by a communication network by carrier current on line of a management system. automatic reading of electric meters.
    With the recent appearance of the Internet of Things (“Internet of Things (ΙοΤ)” in English terminology) a new type of network has appeared: wireless networks with long range and low energy consumption (“ Low Power Wide Area Network (LPWAN) ”(in English terminology). Among these LPWAN networks, one can cite networks based on LoRa technology (registered trademark) ("Long Range" in English terminology) and networks of the company Sigfox.
    A network based on LoRa technology (hereinafter called “LoRa network”) uses a protocol called LoRaWAN. A LoRa network is made up of base stations or gateways (“gateways” in Anglo-Saxon terminology) generally placed at high points in order to cover a large geographic area. The gateways, subsequently called LoRa gateways, are capable of detecting messages sent in their area by equipment or terminals (“endpoints” in English terminology) and of relaying them to at least one server (“LoRa Network Server ( LNS) "in English terminology), called LNS server thereafter, which will process them.
    In a conventional operation of a LoRa network, a terminal wishing to transmit a message (i.e. data) to the LNS server, transmits this message in a frame, called an upstream LoRa frame, conforming to the LoRaWAN protocol. The rising LoRa frame is transmitted in multicast mode ("broadcast" in English terminology). This rising LoRa frame is received by at least one LoRa gateway. Each LoRa gateway having received the rising LoRa frame decodes it and retransmits the message to the server in an HTTP request (hypertext transfer protocol, “HyperText Transfer Protocol” in English terminology). If several LoRa gateways have received the rising LoRa frame, the server receives several HTTP requests containing the message. The server must then designate, among the LoRa gateways having received the uplink LoRa frame, the LoRa gateway to be used to relay a response to the message contained in the uplink LoRa frame. The response is transmitted from the server to the LoRa gateway designated in an HTTP request, then in point-to-point, from the designated LoRa gateway to the terminal in a downward LoRa frame conforming to the LoRaWAN protocol.
    Although LPWAN networks are spreading more and more, there are areas beyond the reach of these networks. These areas then do not have access to the Internet of Things.
    Other networks offer much finer coverage of territories, especially in developed countries. We can especially think of electrical networks. Electric networks, which were originally intended exclusively for the transport of electricity, have recently evolved into networks in which data can circulate. On-line carrier communication networks (“PowerLine Communications” in English terminology) for AMM-type systems (automatic management of meter readings, “Automated Meter Management” in English terminology) thus use infrastructure electrical networks to create a network, called a logical network. Among these logical networks, called PLC networks (Line Carrier Currents), we can cite networks conforming to PRIME specifications ("PoweRline Intelligent Metering Evolution" in English terminology) or networks conforming to the G3PLC standard specified in the ITU recommendation. T G.9903. In PLC networks, communications are established between so-called smart electrical meters (“smart electrical meters” in English terminology), and a device called “data concentrator” (“data concentrator” in English terminology) to allow in particular automated remote reading of electricity consumption measurements made by said smart electric meters. Thereafter we simply call a counter each intelligent electric meter. A plurality of data concentrators is typically geographically deployed in a PLC network so as to distribute the remote management load of a multitude of meters. Each data concentrator is itself connected to the same centralized unit allowing the management of the AMM type system which is managed by an operator of the power supply network to which said meters are connected.
    As the acronym AMM indicates, PLC networks, for AMM-type systems, are intended to transport metrology data from meters.
    Nothing is planned, either in material or in protocol terms, to transport anything other than metrology data from meters. The electrical networks, which, unlike the LPWAN networks, finely cover the territories, cannot therefore, at present, be used to transport data coming from connected objects in areas not covered by the LPWAN networks.
    It is desirable to overcome these drawbacks of the state of the art. It is in particular desirable to propose a method and a device making it possible to benefit from the coverage of a PLC network for AMM type systems to route data coming from connected objects to an LNS server which would be out of range of a LPWAN network. The method and the device must preferably ensure backward compatibility with existing systems and in particular with existing LNS servers. Since metrology data has priority over PLC networks for AMM-type systems, the proposed process must also ensure that the transport of data from connected objects does not affect the transport of metrology data.
    It is moreover desirable to provide a solution which is simple to implement and at low cost.
    According to a first aspect of the present invention, the present invention relates to a device for exchanging first frames, called LPWAN frames, between a terminal and a server, said terminal being adapted to exchange LPWAN frames with at least one gateway, called LPWAN gateway, via a first long-range, low-power wireless network, and the server being adapted to exchange LPWAN frames with LPWAN gateways, each LPWAN frame exchanged between the terminal and the server having to pass through at least one counter and a data concentrator included in a second communication network by carrier current online and forming a system for automatic management of readings from a plurality of electric meters, called AMM system, at least one counter of said AMM system implementing an LPWAN gateway and comprising a communication interface allowing it to exchange manage LPWAN frames with said terminal via the first network. The device is connected to each data concentrator via a third network and to the server via a fourth network and in that each LPWAN frame exchanged between said terminal and the server passes through the device, each LPWAN frame exchanged between the device and the server is encapsulated in a second frame conforming to a frame format that the server would exchange with an LPWAN gateway, and when an LPWAN frame sent by the terminal is received directly by a plurality of counters and by a plurality of data concentrators of the second network so that the device receives several copies of the LPWAN frame, the device is adapted to transmit a single copy of the LPWAN frame to the server, said LPWAN frame being associated in the second frame with information representative of one of the meters having directly received the LPWAN frame chosen by the intermediai system re according to a predetermined criterion.
    According to a second aspect of the invention, the invention relates to a communication system comprising a terminal and a server, said terminal being suitable for exchanging LPWAN frames with at least one gateway, called an LPWAN gateway, via a first wide-area, low-power df-free network, and the server being suitable for exchanging LPWAN frames with LPWAN gateways, each frame exchanged between the terminal and the server having to pass through a counter and a data concentrator included in a second on-line carrier communication network of an automatic management system for reading a plurality of electric meters, known as meters, said meters of the plurality of meters being connected to at least one data concentrator via the second network, at least one of the plurality of meters implementing an LPWAN gateway and comprising an interface communication allowing it to exchange LPWAN frames with said terminal via the first network. The system includes a device according to the first aspect.
    According to a third aspect of the invention, the invention relates to a method for exchanging first frames, called LPWAN frames, between a terminal and a server, said terminal being adapted to exchange LPWAN frames with at least one gateway, called LPWAN gateway, via a first wide range, low power consumption fd network, and the server being adapted to exchange LPWAN frames with LPWAN gateways, each LPWAN frame exchanged between the terminal and the server having to pass through at least one counter and a data concentrator linked together by a second communication network by carrier current online and forming a system for automatic management of readings from a plurality of electric meters, at least one counter implements a gateway LPWAN and includes a communication interface allowing it to exchange LPWAN frames with said terminal by the intermediary of the first network. The method is executed by an intermediate device connected to each data concentrator via a third network and to the server via a fourth network so that each LPWAN frame exchanged between said terminal and the server passes through the intermediate device, each LPWAN frame exchanged between the intermediate device and the server being encapsulated in a second frame conforming to a frame format that the server would exchange with an LPWAN gateway, and comprises: receiving (415) one or more copies of a same LPWAN frame sent by the terminal from a plurality of data concentrators, the LPWAN frame having been received directly by a plurality of counters; and, transmit a single copy of the LPWAN frame to the server, said LPWAN frame being associated in the second frame with information representative of one of the counters having directly received the LPWAN frame, chosen by the intermediate system according to a predetermined criterion.
    According to one embodiment, the predetermined criterion consists in choosing the first copy of the LPWAN frame received or randomly a copy of the LPWAN frame or a copy of the LPWAN frame received with the best quality by a counter from the second network.
    According to one embodiment, when following the transmission of an LPWAN frame to the server, the LPWAN frame having been received directly by a plurality of counters, the intermediate device receives a response frame intended for the terminal from the server, the server having inserted into the response frame an identifier of a counter chosen by the server to relay said response frame to the terminal, the method comprises: determining the counter of the plurality of counters having received the LPWAN frame with the best quality; and, insert an identifier of the determined counter in the response frame in place of the identifier inserted by the server.
    According to one embodiment, each LPWAN frame included in a second frame is encapsulated in JSON format.
    According to a fourth aspect of the invention, the invention relates to a computer program comprising instructions for implementing, by a device, the method according to the third aspect when said program is executed by a processor of said device.
    According to a fifth aspect of the invention, the invention relates to storage means, storing a computer program comprising instructions for implementing, by a device, the method according to the first aspect when said program is executed by a processor of said device.
    The characteristics of the invention mentioned above, as well as others, will appear more clearly on reading the following description of an exemplary embodiment, said description being made in relation to the accompanying drawings, among which:
    - Fig. 1 schematically illustrates an example of an AMM type system in which the invention is implemented;
    - Fig. 2 schematically illustrates a representation of a logical network corresponding to a physical network illustrated in FIG. previous;
    - Fig. 3 schematically illustrates an example of hardware architecture of a processing module;
    - Fig. 4 schematically illustrates an example of implementation in an AMM type system of a method for routing frames transmitted by a terminal on an LPWAN type network;
    - Fig. 5 schematically illustrates an encapsulation of a rising LoRa frame in a G3-PLC frame;
    - Fig. 6 schematically illustrates an encapsulation of a rising LoRa frame in an HTTP frame;
    - Fig. 7 schematically illustrates an encapsulation in JSON format of a rising LoRa frame in an HTTP frame;
    - Fig. 8 schematically illustrates an encapsulation in JSON format of a descending LoRa frame in an HTTP frame;
    - Fig. 9 schematically illustrates an encapsulation of a descending LoRa frame in an HTTP frame;
    - Fig. 10 schematically illustrates an encapsulation of a descending LoRa frame in a G3-PLC frame; and,
    - Fig. 11 schematically illustrates a connection authorization procedure adapted to the invention.
    The invention is described in the context of the PLC network of an AMM type system in which communications are based on the G3-PLC protocol. In addition, as we will see below, certain meters of the PLC network include a communication interface making it possible to communicate on an LPWAN network of LoRa type using frames conforming to the LoRaWAN protocol. The invention could just as easily be used in another context. The AML-type system PLC network could just as well use communications based on the PRIME specifications. Furthermore, the LPWAN network could be a SigFox network.
    Fig. 1 schematically illustrates an example of an AMM type system in which the invention is implemented.
    The AMM type system of FIG. 1 includes a termination system, known as the UES system (“Head End System (HES)” in English terminology) 140. The HES system 140 receives measurement information of electrical consumption collected by a plurality of counters 120A, 120B, 120C , 120D and 120E (denoted 120A-E) and processes them. To allow said counters to transmit said information to the HES system 140, PLC communications are established between each of said counters and a data concentrator 110. The communication system typically comprises a plurality of data concentrators 110, only one being shown in FIG. . 1. Each data concentrator 110 is logically connected to a plurality of counters.
    A PLC network 101 is thus formed between each data concentrator 110 and the plurality of counters which is connected to it. This PLC network 101 is based on an electrical distribution network 100 (i.e. physical network) used to supply electricity to the electrical installations that said meters 120A-E are responsible for monitoring. Each counter 120A-E thus comprises a PLC communication interface 111 making it possible to communicate via the PLC network 101. Likewise, each data concentrator 110 includes such a PLC communication interface 111 making it possible to communicate via the PLC network 101. According to an example of implementation, the PLC network 101 conforms to the G3-PLC protocol.
    In Fig. 1, each counter 120A-E comprises a communication interface 114 with a network of LPWAN type of LoRa type, called LoRa network. The LoRa network allows each counter 120A-E to communicate with terminals which are within the range of said counters, each terminal being connected to the LoRa network by means of the same communication interface 114. In FIG. 1, two terminals of connected object type 160A and 160B are shown. The 120A-E meters and the 160A and 160B terminals communicate according to the protocol
    Lorawan. In Fig. 1, each upstream LoRa frame sent in multicast mode by the terminal 160A is received by the counters 120B and 120C. Each uplink LoRa frame sent in multicast mode by the terminal 160B is received by the counter 120D.
    Each uplink LoRa frame sent by a terminal is intended for a server 150, called the LoRa network server (“LoRa Network Server (LNS)” in English terminology) or LNS server. The LNS server 150 receives the upstream LoRa frames collected by the data concentrator 110 and processes them.
    Placed between each data concentrator 110 and the HES 140 system and the LNS server 150, the system of FIG. 1 comprises an intermediate system 130, called the retransmission network system or FNS system ("Forwarding Network Server" in English terminology). Each frame exchanged between each data concentrator 110 and the HES system 140 or the LNS server 150 passes through the FNS system 130.
    To relay the information transmitted by the counters 120A-E to the HES system 140, each data concentrator 110 further comprises an interface 115 for communication with a communication network 103, to which the FNS system 130 is also connected.
    The FNS system 130 thus comprises an interface 115 for communication via the communication network 103 allowing it to communicate with a plurality of data concentrators 110. The communication network 103 is preferably a network of IP type ("Internet Protocol" in English terminology). , as defined in normative document RFC 791), such as the Internet. In one embodiment, the communications between each data concentrator 110 and the FNS system 130 use HTTP requests.
    The HES system 140 and the LNS server 150 thus comprise a communication interface 113 via a communication network 102 allowing them to communicate with the FNS system 130. The FNS system 130 thus comprises a communication interface 113 via the communication network 102 itself allowing communication with the HES system 140 and the LNS server 150. The communication network 102 is preferably an IP type network. In one embodiment, communications between the HES 140 system (respectively the LNS server 150) and the FNS system 130 use HTTP requests.
    The FNS system 130 is therefore connected to each data concentrator 110 via the network 103 and to the LNS server 150 via the network 102.
    In the system of FIG. 1, each counter having a communication interface 114 implements a LoRa gateway and therefore plays a role similar to a LoRa gateway in a conventional LoRa network with respect to the terminals. However, as we will see later in relation to Figs. 2 and 4, to avoid overloading the AMM-type system with LoRa requests, all uplink LoRa requests received by a counter 120A-E are not sent back to the FNS 130 system.
    Each entity of the system of FIG. 1, whether it is a data concentrator 110, a counter 120A-E, the FNS system 130, the HES system 140 and the LNS server 150, comprises a processing module 30 (not shown) allowing these entities to contribute to a implementation of the invention.
    FIG. 2 schematically illustrates a representation of a logic network corresponding to the PLC network implemented on the electrical network 100 illustrated in FIG. 1.
    As we have mentioned in connection with FIG. 1, each counter 120AE is connected to a data concentrator 110. On the other hand, from a logical point of view, certain counters, such as the counters 120A and 120D are connected directly to the data concentrator 110 while other counters, such as the counters 120B, 120C and 120E are indirectly connected to the data concentrator 110 via another counter. Thus, the counters 120A and 120D can communicate directly with the data concentrator 110. On the other hand, each frame conforming to the G3-PLC standard, called frame G3-PLC thereafter, transmitted by the counters 120B, 120C and 120E must pass through the counter 120A to reach the data concentrator 110. A parent / child hierarchy is therefore created between certain counters. For example, the counter 120A is related to the counters 120B, 120C and 120E, which are themselves children of the counter 120 A.
    As we have seen in relation to FIG. 1, each rising LoRa frame sent by the terminal 160A is received by the counters 120B and 120C. Consequently, when a rising LoRa frame is transmitted by the terminal 160A, it is received by the counter 120B which relays it to the counter 120A and by the counter 120C which also relays it to the counter 120A. The same rising LoRa frame is therefore received twice by the counter 120A. In a traditional LoRa network, each LoRa gateway receiving an uplink LoRa frame, relays it to an LNS server with which it is connected. A LoRa gateway does not care whether one or more other LoRa gateways have relayed the same uplink LoRa frame. In a typical LoRa network, a LoRa gateway receiving a rising LoRa frame has no way of knowing whether this rising LoRa frame has been received and relayed to the LNS server by another LoRa gateway.
    As can be seen in Fig. 2, the situation is different when the Lora gateway is integrated into a meter such as the 120A-E meters. Indeed, some counters, like the counter 120A, due to the organization according to a parent / child hierarchy of counters in the AMM type system, receive the same frame several times. By analyzing the rising LoRa frames it receives, a counter can know that it is receiving the same rising LoRa frame several times.
    Fig. 3 schematically illustrates an example of hardware architecture of the processing module 30.
    The processing module 30 then comprises, connected by a communication bus 300: a processor or CPU 301; a random access memory RAM 302; ROM 303; a storage unit or storage media reader, such as an SD 304 card reader; a set of communication interfaces 305 allowing the processing module 30 to communicate with other entities of the system of FIG. The
    When the processing module 30 is included in a counter 120A-E, the set of communication interfaces 305 comprises the communication interface 111 to the PLC network 101 and the communication interface 114 to an LPWAN network.
    When the processing module 30 is included in a data concentrator 110, the set of communication interfaces 305 comprises the communication interface 111 to the PLC network 101 and the communication interface 115 to the communication network 103.
    When the processing module 30 is included in the FNS system 130, the set of communication interfaces 305 includes the communication interface 113 to the network 102 and the communication interface 115 to the network 103.
    When the processing module 30 is included in the HES system 140, the set of communication interfaces 305 includes the communication interface 113 to the network 102.
    When the processing module 30 is included in the LNS server 150, the set of communication interfaces 305 includes the communication interface 113 to the network 102.
    When the processing module 30 is included in a terminal 160A or 160B, the set of communication interfaces 305 includes the communication interface 114 to the LPWAN network.
    The processor 301 is capable of executing instructions loaded into the RAM 302 from the ROM 303, from an external memory (not shown), from a storage medium, such as an SD card, or from a communication network. When the entity (ie the data concentrator 110, a counter 120A-E, the ENS system 130, the HES system 140, the LNS server 150, a terminal 160A or 160B) is powered up, the processor 301 is capable of read instructions from RAM 302 and execute them. These instructions form a computer program causing the implementation, by the processor 301, of a process described in connection with the Eig. 4.
    All or part of the process described in relation to Eig. 4 can be implemented in software form by execution of a set of instructions by a programmable machine, such as a DSP ("Digital Signal Processor" in English terminology) or a microcontroller, or be implemented in hardware form by a machine or a dedicated component, such as an LPGA (“Lield-Programmable Gate Array” in Anglo-Saxon terminology) or an ASIC (“Application-Specific Integrated Circuit” in Anglo-Saxon terminology).
    FIG. 4 schematically illustrates an example of implementation in a system of AMM type of a method making it possible to route frames transmitted by terminals on a network of LPWAN type.
    In Eig. 4 we take the example of a rising LoRa frame sent by terminal 160A. A similar implementation would have been obtained for a rising LoRa frame sent by the terminal 160B.
    In a step 401, the processing module 30 of the terminal 160A causes a sending of a rising LoRa frame to be sent. This rising LoRa frame is transmitted in multicast mode via the communication interface 114 of the terminal.
    160A. The upstream LoRa frame includes an identifier of the terminal 160A in the form of a DevAddr address.
    In a step 402, the processing module 30 of the counter 120B detects a reception by the counter 120B on its communication interface 114 of the rising LoRa frame.
    Although these two frames are identical, hereinafter we call the rising LoRa frame when it is sent by the terminal 160A, frame sent and the rising LoRa frame when it is received by a counter, for example here the counter 120B, frame received.
    In a step 403, in order to decide whether the frame received by the counter 120B must be relayed, the processing module 30 of the counter 120B determines whether this frame meets a predetermined criterion.
    In one embodiment, called non-timed mode, the predetermined criterion consists in systematically selecting the frame corresponding to said transmitted frame received first by the counter 120B.
    In one embodiment, known as the first timed mode, during step 403, the processing module 30 is put on hold for a predetermined period TEMPO following the first reception of a frame corresponding to the same transmitted frame. The predetermined TEMPO period is for example "200" ms. In this embodiment, the predetermined criterion consists in randomly selecting a frame from the frames corresponding to said transmitted frame received by the counter 120B during the predetermined period TEMPO.
    In one embodiment, known as the second timed mode, during step 403, the processing module 30 is put on hold during the predetermined period TEMPO following the first reception of a frame corresponding to the same transmitted frame. In this embodiment, the predetermined criterion consists in selecting the frame offering better reception quality from among the frames corresponding to said transmitted frame received during the predetermined period TEMPO.
    Frames that do not meet the predetermined criteria are systematically rejected.
    In the case of Lig. 4, the counter 120B only receives the frame sent by the terminal 160A. Consequently, whatever the embodiment, the only frame received is selected to be relayed.
    In a step 404, the processing module 30 of the counter 120B encapsulates the frame received in a G3-PLC frame and transmits this G3-PLC frame towards the data concentrator 110. The counter 120B therefore transmits the G3-PLC frame to the counter 120A. The G3-PLC frame sent by the counter 120B is hereinafter called the first G3-PLC frame.
    Fig. 5 schematically illustrates an encapsulation of a rising LoRa frame in a G3-PLC frame.
    The frame shown in FIG. 5 is therefore a frame conforming to the G3-PLC standard. This G3-PLC frame includes in a subpart 56, a G3-PLC header, in a subpart 55, a 6LowPAN header (Low power wireless local area network IPv6: "IPv6 Low power Wireless Personal Area Networks" in terminology Anglo-Saxon), in a subpart 54, an IPv6 header (Internet Protocol version 6: "Internet Protocol version 6" in English terminology) and in a subpart 53, a UDP header (User datagram protocol: "User Datagram Protocol "in Anglo-Saxon terminology). The G3-PLC frame further comprises a first sub-part 51 comprising the encapsulated rising LoRa frame and a second sub-part 52. The sub-parts 51 and 52 form a useful part of the G3-PLC frame. The second sub-part 52 is intended to receive identifiers from each counter which has received directly (i.e. through a network interface 114) the encapsulated LoRa frame. In one embodiment, each LoRa gateway implemented by a counter has an IP address (Internet Protocol: “Internet Protocol” in English terminology). In this case, the identifier of a counter having received the upstream LoRa frame is the IP address of the LoRa gateway implemented by this counter.
    In these embodiments, during step 404, the counter 120B stores in sub-part 52 the identifier of the counter 120B.
    In one embodiment, in addition to storing an identifier of each counter having received the rising LoRa frame, the subpart 52 stores for each counter having received the rising LoRa frame, information representative of a quality of reception of said frame LoRa rising by said counter. The quality information is for example a signal to noise ratio ("signal to noise ratio (SNR)" in English terminology) and / or an indication of the strength of the received signal ("received signal strength indication (RSSI)" in Anglo-Saxon terminology).
    In this embodiment, the sub-part 52 includes information representative of the quality of reception by the counter 120B of the frame transmitted by the terminal 160 A.
    In a step 406, the processing module 30 of the counter 120C detects a reception by the counter 120C on its communication interface 114, of the frame transmitted by the terminal 160A.
    In a step 407, the processing module 30 of the counter 120C applies a step identical to the step 403. The result of step 407 is then identical to the result of step 403, since the processing module 30 of the counter 120C selects the only frame received and relays this frame in step 408 towards the data concentrator 110 in a G3-PLC frame. The G3-PLC frame sent by the counter 120C is hereinafter called the second G3-PLC frame.
    The second frame G3-PLC uses the frame format described in relation to the Lig. 5. In sub-part 51, it includes the same rising LoRa frame as the first G3-PLC frame. In subpart 52, it includes the identifier of the counter 120C. In one embodiment, the sub-part 52 also includes information representative of a quality of reception of said uplink LoRa frame by the counter 120C.
    In steps 405 and 409, the processing module 30 of the counter 120A receives respectively the first frame G3-PLC and the second frame G3-PLC on its communication interface 111.
    In a step 410, the processing module 30 of the counter 120A applies a step identical to the steps 403 and 407. However, while the steps 403 and 407 were executed in a context where the counters 120B and 120C each received only one frame corresponding to the frame sent, during step 410, the counter 120A receives two frames corresponding to the frame sent.
    In the case of non-timed mode, the processing module 30 of the counter 120A selects in a step 411 the first frame received corresponding to the frame sent upon receipt of this frame. The frame received during step 405 is therefore selected to be relayed.
    In the case of the first timed mode, the processing module 30 of the counter 120A randomly selects, during step 411, a frame from the frames corresponding to the transmitted frame which it has received. For example, the processing module 30 of the counter 120A selects the frame received during step 405 (i.e. the first frame G3-PLC).
    In the case of the second timed mode, the processing module 30 of the counter 120A selects, in step 411, the frame offering the best reception quality among the frames corresponding to the transmitted frame that it has received. To do this, the processing module 30 of the counter 120A uses the information representative of a quality of reception contained in the subpart 52 of each G3-PLC frame received (i.e. the first and the second G3-PLC frame). For example, the processing module 30 of the counter 120A, selects the frame received during step 409 (i.e. the second frame G3-PLC).
    In a step 412, the processing module 30 of the counter 120A causes the relay of the selected frame to the data concentrator 110. The relayed frame respects the frame format described in relation to FIG. 5. During step 412, the relayed frame comprises the rising LoRa frame sent by the terminal 160A during step 401 in its sub-part 51. Furthermore, during step 412, the relayed frame comprises in its sub-part 52, the identifier of each counter having directly received the rising LoRa frame (here this corresponds to the counters 120B and 120C). In one embodiment, the sub-part 52 further comprises, for each counter having directly received the uplink LoRa frame sent by the terminal 160A, information representative of a quality of reception of said frame by the counter. In the example of Fig. 4, the relayed G3-PLC frame comprises information representative of the quality of reception of the rising LoRa frame by the counter 120B and information representative of the quality of reception of the rising LoRa frame by the counter 120C.
    In a step 413, the processing module 30 of the data concentrator 110 detects that the data concentrator 110 has received a G3-PLC frame. In step 413, the useful part of the G3-PLC frame is extracted and encapsulated in an HTTP frame.
    Fig. 6 schematically illustrates an encapsulation of a rising LoRa frame in an HTTP frame.
    The HTTP frame includes in a subpart 66 for example an Ethernet header, in a subpart 65 an IP header (IPv4 or IPv6), in a subpart 64 a TCP header (transmission control protocol: "transmission control protocol (TCP) "in English terminology) and in a sub-part 63 an HTTP header.
    We find in a useful part of the HTTP frame the sub-part 51 and the sub-part 52 comprising in particular the identifier of each counter having relayed the rising LoRa frame (that is to say comprising for each counter having relayed the up LoRa frame, the IP address of the LoRa gateway implemented by said counter). Alternatively, one can use the TLS protocol (“Transport Layer Security” in English terminology) with HTTP, which corresponds to HTTPS (“Hyper Text Transfer Protocol Secure” in English terminology), so as to transmit in a manner secure.
    In a step 414, the processing module 30 of the data concentrator 110 transmits the HTTP frame towards the ENS system 130.
    The data concentrator 110 is conventional. It simply relays the useful part of a G3-PLC frame in an HTTP frame to the system 130, without being concerned with the content of this useful part. The data concentrator 110 cannot tell the difference between a useful part containing metrology data emanating from a meter or data conforming to the LoRaWAN protocol.
    During a step 415, the processing module 30 of the LNS system 130 detects that the LNS system 130 has received an HTTP frame. In step 415, the processing module 30 of the LNS system 130 determines for the received HTTP frame, if the HTTP frame contains metrology data emanating from a counter or if it contains data conforming to the LoRaWAN protocol. To do this, the processing module 30 of the LNS system 130 determines whether the useful part of the HTTP frame contains sub-parts 51 and 52.
    When the HTTP frame includes metrology data, the useful part of the HTTP frame is extracted and encapsulated in a new HTTP frame which is transmitted towards the HES 140 system.
    When the HTTP frame comprises subparts 51 and 52, the processing module 30 of the LNS system 130 transmits the information contained in the rising LoRa frame in an HTTP frame to the LNS server 150. However, the LNS server 150 is an LNS server conventional intended to operate in a conventional LoRa network and therefore to receive HTTP frames comprising uplink LoRa frames from conventional LoRa gateways. The LNS 130 system must therefore transmit to the LNS 150 server HTTP frames conforming to what a conventional LoRa gateway would have transmitted. To do this, the LNS 130 system uses a data encapsulation format understood by all the LNS servers currently used such as the JSON format (JavaScript object notation, “JavaScript Object Notation” in English terminology) described in the document "RFC7159: The JavaScript Object Notation (JSON) Data Interchange Format". In one embodiment, the rising FoRa frame included in the sub-part 51 is encapsulated in a container conforming to the JSON format. In another embodiment, the data included in the rising FoRa frame included in subpart 51 are extracted from the rising FoRa frame, represented in the JSON format and inserted in the HTTP frame to be transmitted to the FNS server 150. For the two embodiments, we will say below that the rising FoRa frame is encapsulated in JSON format.
    In a conventional FoRa network, a FoRa gateway relaying an uplink FoRa frame from a terminal to an FNS server in an HTTP frame, inserts an identifier allowing it to be recognized, such as its IP address, in the HTTP frame. When several FoRa gateways relay the same uplink FoRa frame to an FNS server, the FNS server uses the identifier of each FoRa gateway which has carried out the relay to designate the FoRa gateway which must relay a downward FoRa frame intended for the terminal at the origin of the rising frame.
    In the example of Fig. 4, the FNS system 130 receives an HTTP frame comprising, in the subpart 51, an uplink Fora frame, and in the subpart 52, an identifier of each counter that directly received the uplink FoRa frame from the terminal 160A , that is to say an identifier of the counters 120B and 120C. In one embodiment, the sub-part 52 also includes, for each counter having directly received the rising FoRa frame, information representative of the quality of reception of said rising FoRa frame by said counter.
    In order to conform to the HTTP frames that a conventional FoRa gateway would transmit to the FNS 150 server, each HTTP frame generated by the FNS 130 system can only include a counter identifier, this identifier being understood by the FNS 150 server as an identifier of FoRa gateway. The processing module 30 of the FNS system 130 therefore chooses one of the identifiers which it has received in subpart 52, which amounts to choosing the counter having this identifier.
    In one embodiment, the module 30 of the FNS system 130 randomly chooses an identifier from among the identifiers received in the sub-part 51 of the HTTP frame received during step 415.
    In one embodiment, when the sub-part 52 includes information representative of the quality of reception for each counter having directly received the rising LoRa frame, the module 30 of the FNS system 130 chooses the identifier received in the sub-part 51 of the HTTP frame received during step 415 corresponding to the best information representative of the quality of reception.
    Fig. 7 schematically illustrates an encapsulation in JSON format of a rising LoRa frame in an HTTP frame.
    We find in the HTTP frame shown in Fig. 7, subparts 63, 64, 65 and 66 already explained. The HTTP frame further comprises a subpart 71. The subpart 71 comprises the rising LoRa frame included in the subpart 51 encapsulated in the JSON format. In addition, the subpart 71 includes the identifier of the counter that directly received the rising LoRa frame. As we saw above, this identifier is the IP address of the LoRa gateway implemented by said counter. In the example of Fig. 4, this rising LoRa frame is the one which was selected during step 411.
    In a step 416, the processing module of the LNS server 150 detects that the LNS server 150 has received the HTTP frame sent during step 415 and processes this HTTP frame.
    In a traditional LoRa network, the exchange of messages between a terminal and an LNS server is bidirectional. An LNS server can, for example, acknowledge a rising LoRa frame. To do this, as we saw above, if several LoRa gateways have received the same uplink LoRa frame, the LNS server must designate among the LoRa gateways having received the uplink LoRa frame, the LoRa gateway to be used to relay a response to the message contained in the rising LoRa frame. The response is transmitted from the LNS server to the LoRa gateway designated in an HTTP request, then in point-to-point, from the designated LoRa gateway to the terminal in a downward LoRa frame conforming to the LoRaWAN protocol.
    In the context of the invention, the presence of the FNS 130 system makes it possible to mask the passage of the uplink LoRa frame by the AMM type system to the LNS server 150. From the point of view of the LNS server 150, the HTTP frame received during step 416 was transmitted by a conventional LoRa gateway following reception by said conventional LoRa gateway of an uplink LoRa frame coming from the terminal 160A. The LNS server 150 does not know that the rising LoRa frame has been received by at least one counter implementing a LoRa gateway. The LNS 150 server reacts in the same way to the reception of the HTTP frame via the FNS 130 system as if it had received this HTTP frame from a gateway
    LoRa classic. However, due to the elimination of duplicate upstream LoRa frames between the meters and the LNS 130 system, everything happens as if the upstream LoRa frame transmitted by the terminal 160A had only been relayed by a single LoRa gateway. From the LNS 150 server point of view, this LoRa gateway is the one whose identifier is indicated in subpart 71 of the HTTP frame received during step 416.
    In one embodiment, the processing module 30 of the LNS server 150 designates the counter whose identifier appears in the subpart 71 of the HTTP frame received during step 416. From this designation, each frame generated by the LNS server 150 and intended for the terminal 160A, will pass through the counter whose identifier appears in the subpart 71 of the HTTP frame received during step 416.
    Subsequently, we assume that the rising LoRa frame sent during step 401 by the terminal 160A is a connection request frame ("Join Request" in English terminology). In this case, the method described in relation to Lig. 4 is the start of a connection procedure corresponding to a connection request phase.
    In step 416, the LNS server 150 therefore receives in the subpart 71 from at least one HTTP frame, a connection request frame.
    Following receipt of the connection request frame, the LNS 150 server responds with a connection authorization frame ("JOIN ACCEPT" in English terminology).
    Fig. It schematically illustrates a connection authorization procedure.
    In a step 1101, the processing module of the LNS server 150 generates a downward LoRa frame containing a connection authorization, called connection authorization frame, intended for the device 160A, encapsulates the connection authorization frame in an HTTP frame in JSON format and causes the LNS 150 server to transmit the HTTP frame to the FNS 130 system.
    Fig. 8 schematically illustrates an encapsulation of a descending LoRa frame in an HTTP frame in the JSON format.
    We find in the HTTP frame of FIG. 8, subparts 63, 64, 65 and 66. A subpart 81 includes the connection authorization frame and the identifier of the designated meter encapsulated in JSON format. In the example of Fig. 11, this is the 120B counter. Furthermore, the subpart 81 includes a desired emission date of the descending LoRa frame by the designated counter (i.e. the counter
    120B), this date also being encoded in JSON format. This emission date is a relative date compared to a reception date of an uplink LoRa frame by the designated counter.
    In a step 1102, the LNS system 130 receives the HTTP frame encapsulating the connection authorization frame in the JSON format. In step 1102, the processing module 30 of the LNS system 130 extracts from the HTTP frame the connection authorization frame, the identifier of the designated counter and the desired emission date of the downward LoRa frame. The processing module 30 of the LNS system 130 then inserts the connection authorization frame, the identifier of the designated counter and the desired emission date in a new HTTP frame described below in connection with FIG. 9.
    Fig. 9 schematically illustrates an encapsulation of a descending LoRa frame in an HTTP frame.
    We find in the HTTP frame of the Eig. 8, subparts 63, 64, 65 and 66. Subpart 91 includes the connection authorization frame. A sub-part 92 includes the identifier of the designated counter and the desired emission date of the downward LoRa frame by the designated counter.
    Thus, while the HTTP frame generated by the LNS server 150 is a conventional HTTP frame that a conventional LoRa gateway is capable of processing, the HTTP frame generated by the LNS 130 system is specifically defined for a transmission of a downward LoRa frame to a data concentrator.
    In step 1102, the LNS system 130 transmits the HTTP frame to the data concentrator 110.
    In a step 1103, the data concentrator 110 receives the HTTP frame. During step 1103, the processing module 30 of the data concentrator 110 extracts the useful part of the HTTP frame (i.e. the sub-parts 51 and 92) and forms a G3-PLC frame using this useful part.
    Fig. 10 schematically illustrates an encapsulation of a descending LoRa frame in a G3-PLC frame.
    We find in the frame G3-PLC, the subparts 53, 54, 55 and 56. The subpart 51 includes the descending LoRa frame. Sub-part 102 includes the desired emission date of the downward LoRa frame by the designated counter indicated in sub-part 92.
    During step 1103, the processing module 30 of the data concentrator 110 reads the address of the counter designated in the subpart 92 and determines that to reach the designated counter (ie the counter 120B), it must transmit the frame G3PLC that he trained at the 120A meter. The processing module 30 of the data concentrator 110 then causes the G3-PLC frame to be sent to the counter 120A.
    In a step 1104, the counter 120A receives the frame G3-PLC. In step 1104, the counter 120A relays this frame towards the counter 120B.
    In a step 1105, the processing module 30 of the counter 120B detects that the counter 120B has received the frame G3-PLC and extracts the downward LoRa frame from the frame G3-PLC. The processing module 30 of the counter 120B waits for reception of a rising LoRa frame from the terminal 160A. When the processing module 30 of the counter 120B detects a reception of a rising LoRa frame, it notes the date of reception of this rising LoRa frame, adds the value of the desired transmission date contained in the G3-PLC frame received during from step 1105 to the date of reception to obtain an effective date of transmission, and transmits the downward LoRa frame to the terminal 160A at the effective date of transmission thus calculated.
    In a step 1106, the terminal 160A receives the downward LoRa frame.
    In the example of Figs. 4 and 11, the rising LoRa frame is a connection request to the LoRa network and the falling LoRa frame is a connection authorization. The process of Figs. 4 and 11 would work in the same way if the upstream LoRa frame sent by the terminal 160A had been a frame containing a message intended for the LNS server 150 and the downward LoRa frame an acknowledgment frame of the upstream LoRa frame.
    Until then, we have assumed that the 120A-E counters are strictly identical. Thus each counter 120A-E comprises an interface having a communication interface 114 and implements a LoRa gateway.
    In one embodiment, all the counters 120A-E implement a LoRa gateway, but do not necessarily include a communication interface 114. A counter 120A-E can therefore implement a LoRa gateway without being able to receive or transmit frames LoRa. For example, in this embodiment, the counter 120A does not include a communication interface 114 but implements a LoRa gateway which allows it to execute in particular steps 405, 409, 410, 411, 412 and 1104.
    In one embodiment, some meters do not have a communication interface 114 and do not implement a LoRa gateway. These counters can then be intermediate counters between two counters implementing a LoRa gateway. These counters then only relay G3-PLC frames, without being concerned with the content of these frames.
    When the communication system includes a plurality of data concentrators 110, it is possible that the FNS system 130 receives several HTTP frames encapsulating the same rising LoRa frame from several different data concentrators 110. In this case, the subparts 52 of each HTTP frame received contain information representative of sets of counters having directly received the different uplink LoRa frame. We can indeed imagine that a rising LoRa frame sent by the terminal 160A is received by the counters 120B, 120C and 120D, but that the counters 120B and 120C are attached to a first data concentrator 110 while the counter 120D is attached to a second data concentrator 110.
    In this case, the processing module 30 of the FNS system 130 chooses a rising LoRa frame encapsulated in the subpart 51 of one of the HTTP frames received during step 415.
    In one embodiment, the rising LoRa frame to be relayed to the LNS server 150 is for example that included in the sub-part 51 of the HTTP frame received first by the FNS system 130. In this embodiment, the module processing 30 of the FNS system 130 chooses the counter appearing first among the counters having an identifier in the sub-part 52 of the HTTP frame received first during step 415.
    In one embodiment, the rising LoRa frame to be relayed to the LNS server 150 is for example chosen at random. In this embodiment, the processing module 30 of the FNS system 130 also randomly chooses a counter from the counters having an identifier in the sub-part 52 of one of the HTTP frames received during step 415.
    In another embodiment, the uplink LoRa frame to be relayed is that included in the HTTP frame comprising in its sub-part 52, the best reception quality information. This embodiment amounts to choosing the uplink LoRa frame received with the best reception quality by a counter. In this embodiment, the processing module 30 of the FNS system 130 also chooses the counter associated with the best representative information of quality.
    In one embodiment, the choice of the counter designated by the LNS server 150 can be called into question by the FNS system 130. This embodiment can for example be applied when the subpart 52 of the HTTP frame received by the system FNS 130 comprises a plurality of counter identifiers, each counter identifier being associated with information representative of the quality of reception of the rising LoRa frame, but that the processing module 30 of the FNS 130 system has not chosen the identifier the counter to appear in the HTTP frame intended for the LNS server 150 on the basis of said information representative of a quality of reception. In this case, the identifier of the counter appearing in the HTTP frame received by the LNS 150 server is not necessarily the identifier of the counter that received the rising LoRa frame with the best quality. It is however this counter which is chosen by the processing module 30 of the LNS server 150, since only its identifier appears in the HTTP frame received by the LNS server 150. This case can occur when the FNS system 130 relays the LoRa frame. rising as quickly as possible to the LNS server 150, without waiting to have analyzed the quality information contained in the sub-part 52. In this embodiment, during step 1102, the processing module 30 of the FNS system 130 determines the counter identifier corresponding to the best information representative of a quality of reception and inserts the identifier determined in subpart 92 rather than the counter identifier appearing in subpart 82 included in the received HTTP frame from the LNS 150 server.
    权利要求:
    Claims (8)
    [1" id="c-fr-0001]
    1) Device for exchanging first frames, called LPWAN frames, between a terminal and a server, said terminal being suitable for exchanging LPWAN frames with at least one gateway, called LPWAN gateway, via a first network long range wireless and low power consumption, and the server being adapted to exchange LPWAN frames with LPWAN gateways, each LPWAN frame exchanged between the terminal and the server having to pass through at least one counter and a data concentrator included in a second communication network by carrier current online and forming an automatic management system of readings from a plurality of electric meters, called AMM system, at least one counter of said AMM system implementing an LPWAN gateway and comprising a communication interface (114) allowing it to exchange LPWAN frames with said terminal via the first r bucket, characterized in that the device is connected to each data concentrator (110) via a third network (103) and to the server (150) via a fourth network (102) and that each LPWAN frame exchanged between said terminal (160A) and the server (150) passes through the device (130), each LPWAN frame exchanged between the device (130) and the server (150) is encapsulated in a second frame conforming to a frame format that the server would exchange with an LPWAN gateway, and when an LPWAN frame sent by the terminal is received directly by a plurality of counters and by a plurality of data concentrators of the second network so that the device receives several copies of the LPWAN frame, the device is adapted to transmit a single copy of the LPWAN frame to the server, said LPWAN frame being associated in the second frame with information representative of one of s meters having directly received the LPWAN frame, chosen by the intermediate system according to a predetermined criterion.
    [2" id="c-fr-0002]
    2) Communication system comprising a terminal and a server, said terminal being suitable for exchanging LPWAN frames with at least one gateway, called LPWAN gateway, via a first wide area wireless network with low consumption d energy, and the server being suitable for exchanging LPWAN frames with LPWAN gateways, each frame exchanged between the terminal and the server having to pass through a counter and a data concentrator included in a second communication network by carrier current lines d '' a system for automatic management of readings from a plurality of electric meters (120A, 120B, 120C, 120D, 120E), called counters, said counters from the plurality of counters being connected to at least one data concentrator (110) via the second network, at least one of the plurality of meters implementing an LPWAN gateway and comprising a communication interface (114) p allowing exchange of LPWAN frames with said terminal via the first network, characterized in that the system comprises a device according to claim 1.
    [3" id="c-fr-0003]
    3) Method for exchanging first frames, called LPWAN frames, between a terminal and a server, said terminal being adapted to exchange LPWAN frames with at least one gateway, called LPWAN gateway, via a first network long range wireless and low power consumption, and the server being adapted to exchange LPWAN frames with LPWAN gateways, each LPWAN frame exchanged between the terminal and the server having to pass through at least one counter and a data concentrator interconnected by a second communication network by carrier current online and forming an automatic management system for reading a plurality of electric meters, at least one meter implements an LPWAN gateway and includes a communication interface (114) allowing it to exchange LPWAN frames with said terminal via the first network, characterized in that:
    the method is executed by an intermediate device connected to each data concentrator (110) via a third network (103) and to the server (150) via a fourth network (102) so that each LPWAN frame exchanged between said terminal (160A) and the server (150) passes through the intermediate device (130), each LPWAN frame exchanged between the intermediate device (130) and the server (150) being encapsulated in a second frame conforming to a frame format that the server would exchange with an LPWAN gateway, and includes:
    receive several copies of the same LPWAN frame sent by the terminal from a plurality of data concentrators, the LPWAN frame having been received directly by a plurality of counters; and, transmit a single copy of the LPWAN frame to the server, said LPWAN frame being associated in the second frame with information representative of one of the counters having directly received the LPWAN frame, chosen by the intermediate system according to a predetermined criterion.
    [4" id="c-fr-0004]
    4) Method according to claim 3 characterized in that, the predetermined criterion consists in choosing the first copy of the received LPWAN frame or randomly a copy of the LPWAN frame or a copy of the received LPWAN frame with the best quality by a counter of the second network.
    [5" id="c-fr-0005]
    5) Method according to claim 3 or 4, characterized in that, when following the transmission of an LPWAN frame to the server, the LPWAN frame having been received directly by a plurality of counters, the intermediate device receives a response frame intended at the terminal on the part of the server, the server having inserted into the response frame an identifier of a counter chosen by the server to relay said response frame to the terminal, the method comprises:
    determining the counter the plurality of counters having received the LPWAN frame with the best quality; and, insert an identifier of the determined counter in the response frame in place of the identifier inserted by the server.
    [6" id="c-fr-0006]
    6) Method according to claim 3, 4 or 5 characterized in that, each LPWAN frame included in a second frame is encapsulated in JSON format.
    [7" id="c-fr-0007]
    7) Computer program, characterized in that it comprises instructions for implementing, by a device, the method according to one of claims 3 to 6 when said program is executed by a processor of said device.
    [8" id="c-fr-0008]
    8) Storage means, characterized in that they store a computer program comprising instructions for implementing, by a device, the method according to one of claims 3 to 6 when said program is executed by a processor of said device.
    类似技术:
    公开号 | 公开日 | 专利标题
    EP3598801A1|2020-01-22|Device for transmitting lora frames over a plc network
    EP3588971A1|2020-01-01|Method for transmitting lora frames over a plc network
    FR2919778A1|2009-02-06|METHOD FOR TRANSMITTING DATA PACKETS IN A TUNNEL, COMPUTER PROGRAM PRODUCT, CORRESPONDING STORAGE MEDIUM AND TUNNEL HEAD
    EP3629541A1|2020-04-01|Method of managing roaming by multi-network transfer
    EP3635989B1|2021-11-03|Data transmission between a terminal and an associated server
    EP3135017B1|2020-04-01|Methods of exchanging data with a device comprising radio communication means
    EP3189652B1|2020-11-18|Method of forwarding data between ip devices
    EP3389232B1|2021-03-10|Method for configuration of message distribution
    FR3081271A1|2019-11-22|EQUIPMENT ADAPTED TO BE CONNECTED TO AN AMM TYPE SYSTEM
    EP3817294A1|2021-05-05|Method and module for a connectivity regulation of connected objects.
    EP3734984B1|2021-05-26|Method for reading utility meters
    EP3709185A1|2020-09-16|Method for optimising data exchange in a connected object infrastructure
    EP3846417A1|2021-07-07|Method for sharing iot functionalities and device for sharing
    EP3672209A1|2020-06-24|Method for identifying a communication node
    EP1858224A1|2007-11-21|Method of setting up virtual private networks and remote access control
    FR3087610A1|2020-04-24|EXCHANGE OF DATA IN AN INFRASTRUCTURE OF CONNECTED OBJECTS
    Abane2019|A realistic named data networking architecture for the Internet of things
    FR3078569A1|2019-09-06|METHOD OF TRANSMITTING BY AN INTELLIGENT ELECTRIC COUNTER A MESSAGE REPRESENTATIVE OF DETECTION OF A BREAK OF AN ELECTRIC POWER SUPPLY
    FR2951045A1|2011-04-08|Method for managing size of frames of e.g. audio, stream transmitted between source and destination devices, involves providing adaptation information allowing adaptation of size of packets of stream to source and/or destination device
    FR3079700A1|2019-10-04|TRANSMITTING DATA FROM A MANAGEMENT ENTITY TO AN INTELLIGENT ELECTRIC COUNTER
    FR3074386A1|2019-05-31|MANAGING ACCESS TO A SERVER OF CONTENTS VIA A GATEWAY
    WO2017202743A1|2017-11-30|Method of exchanging data between a connected object and a central server
    FR3059503A1|2018-06-01|ELECTRICAL METER COMPRISING AN IN LINE CARRIER INTERFACE AND AT LEAST ONE RADIO FREQUENCY INTERFACE
    FR2852175A1|2004-09-10|Data processing stations communicating system, has groups of processing stations, where stations of same group communicate via internal network and of different groups communicate via external network
    同族专利:
    公开号 | 公开日
    US10742266B2|2020-08-11|
    EP3598801A1|2020-01-22|
    CN110740010A|2020-01-31|
    US20200028540A1|2020-01-23|
    FR3084233B1|2022-01-28|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    EP3122061A1|2015-07-21|2017-01-25|Sagemcom Energy & Telecom Sas|Transmission of encrypted data from smart electric meters|
    WO2018077790A1|2016-10-28|2018-05-03|Sagemcom Energy & Telecom Sas|Method of selecting a gateway for sending a frame|
    WO2018119235A1|2016-12-21|2018-06-28|Ncore Communications, Inc.|Methods and apparatus for aggregating network access within a single unified platform for a myriad of devices|
    CN107547521A|2017-08-02|2018-01-05|新华三技术有限公司|A kind of message transmitting method and device|
    US6900737B1|1997-02-12|2005-05-31|Elster Electricity, Llc|Remote access to electronic meters using the short message service|
    US20090125351A1|2007-11-08|2009-05-14|Davis Jr Robert G|System and Method for Establishing Communications with an Electronic Meter|
    US9143197B2|2011-10-18|2015-09-22|Texas Instruments Incorporated|Joining process for G3 networks|
    CN106415283A|2014-03-31|2017-02-15|科泰克工业私人有限公司|Wireless power metering and metrics|
    CN107071791A|2017-03-31|2017-08-18|深圳市亿道数码技术有限公司|A kind of network-building method and system based on LoRa|
    CN107769834B|2017-09-30|2020-05-19|中兴克拉科技（苏州）有限公司|LoRaWAN Internet of things signal relay method|CN110557184B|2018-05-31|2021-11-16|阿里巴巴集团控股有限公司|Communication method and device based on relay equipment and communication method and device between terminal and base station|
    FR3083408B1|2018-06-28|2020-09-18|Sagemcom Energy & Telecom Sas|PROCESS FOR TRANSPORTING LORA FRAMES ON A PLC NETWORK.|
    CN111740769A|2020-06-19|2020-10-02|国动物联网有限公司|Repeater based on LoRa radio frequency chip and communication method|
    法律状态:
    2019-06-20| PLFP| Fee payment|Year of fee payment: 2 |
    2020-01-24| PLSC| Publication of the preliminary search report|Effective date: 20200124 |
    2020-06-23| PLFP| Fee payment|Year of fee payment: 3 |
    2021-06-23| PLFP| Fee payment|Year of fee payment: 4 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1856654|2018-07-18|
    FR1856654A|FR3084233B1|2018-07-18|2018-07-18|DEVICE FOR TRANSPORTING LORA FRAMES OVER A PLC NETWORK.|FR1856654A| FR3084233B1|2018-07-18|2018-07-18|DEVICE FOR TRANSPORTING LORA FRAMES OVER A PLC NETWORK.|
    US16/511,535| US10742266B2|2018-07-18|2019-07-15|Device for transporting LoRa frames on a PL network|
    EP19186233.3A| EP3598801A1|2018-07-18|2019-07-15|Device for transmitting lora frames over a plc network|
    CN201910649420.5A| CN110740010A|2018-07-18|2019-07-18|Device for enabling transmission of LoRa frames on a CPL network|
    [返回顶部]